home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000212_owner-urn-ietf _Fri Nov 29 10:43:52 1996.msg < prev   
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA18582 for urn-ietf-out; Fri, 29 Nov 1996 10:43:52 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA18577 for <urn-ietf@services.bunyip.com>; Fri, 29 Nov 1996 10:43:44 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA09022  (mail destined for urn-ietf@services.bunyip.com); Fri, 29 Nov 96 10:43:37 -0500
  5. Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) 
  6.           id <25229-0@josef.ifi.unizh.ch>; Fri, 29 Nov 1996 16:42:11 +0100
  7. Date: Fri, 29 Nov 1996 16:42:08 +0100 (MET)
  8. From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  9. To: Leslie Daigle <leslie@bunyip.com>
  10. Cc: Ryan Moats <jayhawk@ds.internic.net>,
  11.         URN mailing list <urn-ietf@bunyip.com>
  12. Subject: Re: [URN] Collecting open issue information on the syntax draft...
  13. In-Reply-To: <199611221942.OAA21503@beethoven.bunyip.com>
  14. Message-Id: <Pine.SUN.3.95.961129162925.245R-100000@enoshima>
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. On Fri, 22 Nov 1996, Leslie Daigle wrote:
  23.  
  24. > [Ryan brought up:]
  25. > > 4. human readability for new namespaces: MUST/SHOULD?
  26. > 
  27. > If that is the case, I would propose the following change to the syntax
  28. > draft:
  29. > 
  30. > > 3. Support of existing legacy naming systems and new naming systems
  31. > 
  32. >    > URN-aware applications MAY accept as input other resource identifiers
  33. >    > from existing legacy namespaces.  If such identifiers contain
  34. >    > characters that are not members of the URN character set specified in
  35. >    > section 2.2, the identifier MUST be translated to canonical format as
  36. >    > discussed in section 2.2.
  37. > > 
  38. >    > Some existing name spaces that have the properties of the URN-space
  39. >    > contain some human-significant components, and these exist in a wide
  40. >    > variety of languages.  However, URNs are NOT intended to convey
  41. >    > information that is significant to humans.  While the translation
  42. >    > rule in section 2.2 is provided for existing namespaces, new
  43. >    > namespaces, as part of their registration documentation, MUST define
  44. >    > a discipline for assigning new URNs that does not simplify the
  45. >    > generation of human-significant names.
  46. > 
  47. >  would become:
  48. > 
  49. > 
  50. > 3. Support of existing legacy naming systems and new naming systems
  51. > 
  52. >    Any namespace (existing or newly-devised) that is proposed as a 
  53. >    URN-namespace and fulfills the criteria of URN-namespaces must
  54. >    be expressed in this syntax.  If names in these spaces contain
  55. >    characters other than those defined for the URN character set,
  56. >    they must be translated into canonical format as discussed in
  57. >    section 2.2.
  58.  
  59. I can only support Leslie's proposal (just change "spaces" on
  60. line 3 to "name spaces" and "canonical format" to "canonical form".)
  61.  
  62.  
  63. Regards,    Martin.
  64.  
  65.  
  66.